home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18462 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.7 KB  |  87 lines
  1. Path: ix.netcom.com!news
  2. From: Bradd W. Szonye <bradds@ix.netcom.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: RE: int::~int()
  5. Date: 20 Apr 1996 16:45:21 GMT
  6. Organization: Netcom
  7. Message-ID: <01bb2ed9.363f0020$65c2b7c7@Zany.localhost>
  8. References: <199604160100.KAA06143@public1.guangzhou.gd.cn>
  9. NNTP-Posting-Host: det-mi3-05.ix.netcom.com
  10. X-NETCOM-Date: Sat Apr 20 11:45:21 AM CDT 1996
  11. X-Newsreader: Microsoft Internet News
  12.  
  13.  
  14. On Monday, April 15, 1996, Wang TianXing wrote...
  15. > On Sun, 14 Apr 1996 13:49:59 +0900, Xu Yifeng <jafd@public.sta.net.cn>
  16. > wrote:
  17. > 
  18. > | Hi everybody,
  19. > 
  20. > | can your compiler compile following program?
  21. > 
  22. > | //------------------------
  23. > | void main()
  24. > | {
  25. > |      int i = 0;
  26. > 
  27. > |      i.int::~int();
  28. > | }
  29. > | //------------------------
  30. > 
  31. > | is it a legal C++ program?
  32. > 
  33. > Though many guys had said it is a legal one, I don't think it's a
  34. > meaningful one.  The Sep, 95 draft Standard says in 12.4:
  35. > 
  36. > 12 Invocation  of  destructors  is  subject to the usual rules for
  37. >    member functions (_class.mfct_), e.g., an object of the
  38. >    appropriate  type  is required  (except  invoking  delete  on a
  39. >    null pointer has no effect). Once a destructor is invoked for an
  40. >    object,  the  object  no  longer exists;  the behavior is
  41. >    undefined if the destructor is invoked for an object whose
  42. >    lifetime has  ended  (_basic.life_).   [Example:  if  the
  43. >    destructor  for  an  automatic  object  is explicitly invoked,
  44. >    and the block is subsequently left in a manner that  would
  45. >    ordinarily invoke implicit destruction of the object, the
  46. >    behavior is undefined.  ]
  47. > 
  48. > The [Example:...], though it isn't part of the standard, says
  49. > something directly related to your program.
  50. > 
  51. > Although there're some differences between "well-formed program" and
  52. > "undefined behavior", I don't think it's a bad idea that a compiler
  53. > rejects this sort of code, as it will surely cause undefined
  54. > behaviors.
  55. > 
  56. > The plain old Borland C++ 3.1 compiles
  57. > 
  58. >     int i = 0;
  59. >     (&i)->int::~int();
  60. > 
  61. > just fine.  And that's the "Standard" way(via pointer) to explicitly
  62. > call a destructor.
  63.  
  64. The example is contrived; you wouldn't ever want to call a destructor like
  65. that for an automatic object. You might want to do something like that,
  66. though, if you were dealing with a reference to a heap object in a
  67. template class. For another contrived example:
  68.  
  69. template <class T> class Foo {
  70. public:
  71.     Foo(T* bar) { Destroy(*bar); }
  72.     void Destroy(T& bar) { bar.T::~T(); }
  73. }
  74.  
  75. void Bar()
  76. {
  77.     char* s = new char[sizeof(int)];
  78.     Foo<int> test((int*)s);
  79. }
  80.  
  81. That's the kind of circumstance that happens in the STL; you want the
  82. "destroy" function to invoke a destructor on raw memory, regardless of
  83. what type the destroyed object is.
  84.  
  85.  
  86.  
  87.